At 8:20 +0200 on 16/10/98, Aleksey Demakov wrote:
>
> Can you believe me?
>
> I have a table with a column which is to store the dates each row was
> created. I fill it with the line:
>
> insert_stmt.setDate(2, new Date (System.currentTimeMillis ()));
>
> And every day I insert a new row I can see that I did it tomorrow!
>
> I have found that in the method PreparedStatement.setDate() the date
> argument is intentionally incremented by one. The comments there say
> that it's to compensate broken SimpleDateFormat. Apparently, my
> SimpleDateFormat is ok (JDK 1.1.7 for win95/nt and jdk1.1.5 for freebsd).
For some, it works like that, and for some it doesn't. I'll leave it to the
author of the JDBC driver to explain why this is done. The question I ask
is: why do you use the Java current date instead of doing this within the
INSERT itself?
That is, if the column to contain the row creation date is of type
DATETIME, just use now() instead of a ? and a setDate.
INSERT INTO my_table
(creation, other_field1, other_field2, other_field3)
VALUES
('now', ?, ?, ?);
Personally, I do this by defining the creation column as a NOT NULL and
giving it a default (There's a bit of a trick here, because you have to use
a function, or 'now' will be interpreted as the time of the creation of the
table, so I define an SQL function which returns 'now'::DATETIME). This
enables me to use a statement like
INSERT INTO my_table
(other_field1, other_field2, other_field3)
VALUES
(?,?,?);
And not bother myself about the creation dates (which are automatic).
Herouth
--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma